Software applications typically include flaws or defects, causing the software to operate in an unintended or undesired manner. Some defects can also be exploited to gain unauthorized access to the software and/or data associated therewith. Static vulnerability analysis techniques that can analyze the source code and/or one or more compiled binary files corresponding to a software application can be used to detect such vulnerabilities. A static analyzer that can analyze one or more compiled binary files corresponding to a software application is useful at least in situations where the source code is unavailable for a number of reasons, e.g., when the owner of the source code wishes not to disclose the source code to the tester performing the static analysis, when a portion of the binary files is obtained from a third party and the corresponding source code is not available from the third party, etc. As used herein, binary files are not limited to machine code only and may include files that are derived by processing source code and that include representations that are not source code representations, such as byte code, object code, intermediate representation, etc., where these representations are dependent on the respective programming languages used.
One or more binary files associated with a software application typically include several components such as data structures, classes, methods, functions, interfaces, etc. Some components are provided or written by the software developer (also called the first party) and some components may be provided by one or more third parties, such as vendors and providers of open-source code. In many situations, the software developer develops one or more components that are based on or derived from one or more third-party components. In code written in Java, for example, a third party may supply a base class and the software developer may then extend that class.
If only the binary file or files associated with a software application are available for analysis, various software-application components and the intricate relationships therebetween, identifying any third-party components, may not be discerned readily, e.g., by a static analyzer. A runtime environment may load all the required components during execution thereof and can thus identify all the components associated with the software application. Analysis relying on the runtime environment, typically called dynamic analysis, however, can encounter several problems and may not be feasible. For example, the party performing the analysis may not have access to adequate test data, may not have licenses to execute certain third-party components, which can prevent the execution of the software application by the analyzing/testing party. The dynamic analysis may also expose the tester's system vulnerable to any malicious code that may be present in the binaries that are analyzed.
Some static analyzers can determine the intricate relationships between various software components and/or may identify all of the software components associated with the software application to be analyzed/tested, but the static analyzers often do not distinguish between the components supplied by the software developer and those provided by vendors including commercial vendors and those that provide the components as open source. Therefore, the static analysis may not be focused on the developer-supplied components. Some static analyzers may also fail to identify all of the developer-provided software components and, as such, any subsequent analysis of the software application, such as vulnerability analysis, may be incomplete and/or erroneous.